home *** CD-ROM | disk | FTP | other *** search
/ Chip 1996 September / CHIP 1996 szeptember (CD07).zip / CHIP_CD07.ISO / sac / pack / unz520x3.exe / README.DOS < prev    next >
Text File  |  1996-04-26  |  4KB  |  82 lines
  1. Notes about MS-DOS executables and compilers:
  2.  
  3.  - Borland start-up code is reported to switch the screen mode auto-
  4.    matically if it's not 80 columns (or possibly 40) and either 25, 43 
  5.    or 50 lines.  In particular, extended modes such as 100x40 are not
  6.    retained.
  7.  
  8.  - Borland start-up code also uses interrupt 1Ah, causing incorrect
  9.    behavior (including lock-ups) on some Japanese MS-DOS machines such
  10.    as the Fujitsu FMR series, which lack this interrupt.
  11.  
  12.  - Some(?) Borland compilers are apparently incapable of putting static
  13.    data into far memory; this means all of UnZip's strings are in near
  14.    memory, and there is not enough room to enable ZipInfo in the small
  15.    memory model.  The medium memory model is the default for now, but
  16.    it may be necessary in some cases to use the large model.
  17.  
  18.  - Older Borland compilers do not understand source files with Unix
  19.    line-endings (LF rather than CR/LF).  Use "flip" or a similar utility
  20.    to convert the line endings before compiling.
  21.  
  22.  - The Borland 5.00 compiler is simply too buggy to use on WizUnZip, both
  23.    16-bit and 32-bit versions, and we recommend avoiding it for now even
  24.    on the commmand-line version of UnZip.
  25.  
  26.  - Microsoft C 5.1 large-model code is more than an order of magnitude
  27.    slower than the identical code compiled with MSC 6 or 7 (a factor of
  28.    15 in our tests, actually).  This may be due to a lousy optimizer or
  29.    lousy libraries; regardless, since UnZip is hovering at the doorstep
  30.    of the large memory model, we recommend upgrading to a later version
  31.    of the compiler.
  32.  
  33. For these reasons, Info-ZIP's distributed versions of the 16-bit MS-DOS 
  34. executables are compiled with MSC 6 or 7.
  35.  
  36.  - The default wildcard ("globbing") behavior of djgpp/go32 is disabled
  37.    by default in UnZip, but this can be overridden if the GO32 environment
  38.    variable is set to "glob".  This will cause UnZip to fail with various
  39.    odd errors about "filename not matched" and the like; to avoid this, set
  40.    the GO32 variable to "noglob" or unset it altogether.  (The documented
  41.    method of avoiding this by quoting wildcards with single quotes was 
  42.    buggy in djgpp 1.11 but is reported fixed in 1.12; not tested.)
  43.  
  44.  - djgpp's handling of timezones, necessary for the correct conversion of
  45.    MS-DOS filetimes to those used in the Unix-like C library, is completely
  46.    broken in djgpp 1.12 and probably earlier versions as well.  It is fixed
  47.    (or very close to it) in the 1.12m4 patch release and reportedly in the
  48.    2.x series, so be sure to use one of those when compiling.  Otherwise
  49.    UnZip's -f and -u (freshen/update) functions will not work correctly.
  50.  
  51.  - djgpp/go32 executables, when run in a DOS box under OS/2 *and* extracting
  52.    to an HPFS disk *and* overwriting existing files (intentionally, that is),
  53.    do not set the files' timestamps correctly.  Instead, the timestamps re-
  54.    main set to whatever the original files' stamps were.  This is a pretty
  55.    obscure bug, but it does *not* occur in the 16-bit version so it seems
  56.    to be go32's fault somehow.
  57.  
  58.  - According to notes found in another package, there was a known conflict
  59.    between djgpp 1.x's go32 extender and QEMM's DPMI; this was apparently
  60.    fixed in QEMM 7.04/QDPMI 1.05, but if you still have an older version
  61.    (1.03 or 1.01), add "set GO32=nodpmi" to your autoexec.bat to avoid the
  62.    conflict.)
  63.  
  64.  - [For Zip only, the djgpp/go32 extender goes nuts with the copying and/or
  65.    deletion of some sort of a temporary file (swap file?) after compression
  66.    is finished; this can take 30 seconds or more and really hurts perfor-
  67.    mance.  It doesn't affect UnZip, apparently.]
  68.  
  69.  - emx+gcc's DOS extender does not understand DPMI, and while there is an
  70.    alternative extender called RSX available (found in dpmigcc4.zip as of
  71.    August 1994), its setup is somewhat kludgy when the local memory manager
  72.    supports both DPMI and VCPI (or something else).  It's also not yet as
  73.    widely known or available as djgpp.
  74.  
  75. For these reasons Info-ZIP's distributed 32-bit MS-DOS executables will 
  76. probably be compiled with Watcom C 10.x and use the PMODE/W extender.  If
  77. a problem occurs with unzip386.exe, check first if it also occurs with
  78. unzip.exe before reporting it.
  79.  
  80.  
  81. GRR 960427
  82.